Vibe Audit_04_npm 배포와 Show HN
GitHub: Vibe-Audit
공개 가능한 상태로 만들기
코드보다 오래 걸린 건 공개 가능한 상태로 정리하는, 배포 준비 작업이었다.
내 컴퓨터에서 돌아가는 것과 처음 보는 사람이 바로 실행해볼 수 있는 건 완전히 다른 문제다.
README도 다시 썼다. 내부 문서나 임시 산출물을 정리하고 패키지 포함 파일을 최소화했다.
로컬 설정이나 비밀정보가 절대 들어가지 않도록 점검하는 것도 은근 시간이 걸렸다.
작동하는 상태와 공개 가능한 상태의 차이를 배포 직전에 크게 체감했다.
npm 배포
npm 배포에서는 2FA 정책 때문에 좀 헤맸다.
E403 에러가 나오길래 뭔가 했더니 토큰 권한 문제였다.
로컬 1회 배포에는 --otp가 가장 단순하고 자동화하려면 granular token에 publish 권한을 따로 줘야 한다.
package.json의 files 필드도 런타임 파일만 남기도록 정리하고 npm pack --dry-run으로 반복 확인했다.
테스트 파일이나 캐시 같은 게 묻어 들어가면 안 되니까.
GitHub README 렌더링도 신경 쓸 게 많았다.
커스텀 폰트가 안 먹힌다. HTML/CSS도 제한적이다. 타이틀은 로고 이미지로 대체했다.
보여주는 품질도 제품 신뢰의 일부라 대충 넘어갈 수 없었다.
npx vibe-audit 한 줄로 바로 띄울 수 있게 되는 순간은 좀 감격스러웠다. 진짜 도구가 된 느낌.
Show HN
Show HN에 올려봤다.
내가 잡은 원칙은 이렇다.
- 문제를 먼저 말한다
- 해결 범위를 짧고 명확하게 말한다
- 한계를 먼저 공개한다
- 피드백 받고 싶은 포인트를 구체적으로 요청한다
솔직히 반응은 아쉬웠다.
HN 특성상 올리는 타이밍이나 제목의 뉘앙스에 따라 노출 자체가 갈리기도 하고 키워드 자체를 매력적으로 포장하지 못한 이유도 있을 것 같다.
근데 뭐 사실 기대를 많이 한 것도 아니다.
처음부터 내가 쓰려고 만든 도구였고 공개는 실험이나 마찬가지였다. 그리고 포폴 하나 추가했다고 생각하기로 했다. AIOps라던가....
스타가 몇 개 찍히든 안 찍히든 이 도구는 내가 계속 쓸 거다.
CLI마다 동작 편차도 줄여야 하고 장시간 세션 안정성도 더 봐야 한다.
기능 추가보다는 회귀 방지가 먼저고 어디까지 보장하는지를 명확하게 하는 게 다음 과제다.
내가 쓰기에는 충분히 쓸만한 것 같다. 일단은.